Thanks @kazuyukitanimura. This looks good overall, but we need to think about configs for this. We have not enabled any JVM UDFs by default yet - they should be opt-in until the UDF functionality is more mature.

There is a general discussion on the config approach in #4310

Thanks @kazuyukitanimura. This looks good overall, but we need to think about configs for this. We have not enabled any JVM UDFs by default yet - they should be opt-in until the UDF functionality is more mature.

There is a general discussion on the config approach in #4310

Thanks @andygrove
I reverted the changes in native/spark-expr/src/math_funcs/round.rs so that we can choose to use the incompatible native implementations in the future if we need to.
We are currently disabling round by default, no option to enable. This PR returns JVM compatible results at least. What about merging this PR first for now and that will unblock the TPCDS coverage issue?

Test failure:

- round *** FAILED *** (616 milliseconds)
  org.apache.spark.SparkNumberFormatException: [CAST_INVALID_INPUT] The value '-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3-3' of the type "STRING" cannot be cast to "DOUBLE" because it is malformed. Correct the value as per the syntax, or change its target type. Use `try_cast` to tolerate malformed input and return NULL instead. SQLSTATE: 22018
== SQL (line 1, position 12) ==
select _8, round(_8, -5) FROM tbl
           ^^^^^^^^^^^^^

Thanks @kazuyukitanimura. This looks good overall, but we need to think about configs for this. We have not enabled any JVM UDFs by default yet - they should be opt-in until the UDF functionality is more mature.
There is a general discussion on the config approach in #4310

Thanks @andygrove I reverted the changes in native/spark-expr/src/math_funcs/round.rs so that we can choose to use the incompatible native implementations in the future if we need to. We are currently disabling round by default, no option to enable. This PR returns JVM compatible results at least. What about merging this PR first for now and that will unblock the TPCDS coverage issue?

This PR enabled a Comet JVM UDF by default. This would be the first one if we merge it. I don't know if we are ready to enable JVM UDF by default yet.

Thanks @kazuyukitanimura. This looks good overall, but we need to think about configs for this. We have not enabled any JVM UDFs by default yet - they should be opt-in until the UDF functionality is more mature.
There is a general discussion on the config approach in #4310

Thanks @andygrove I reverted the changes in native/spark-expr/src/math_funcs/round.rs so that we can choose to use the incompatible native implementations in the future if we need to. We are currently disabling round by default, no option to enable. This PR returns JVM compatible results at least. What about merging this PR first for now and that will unblock the TPCDS coverage issue?

This PR enabled a Comet JVM UDF by default. This would be the first one if we merge it. I don't know if we are ready to enable JVM UDF by default yet.

Perhaps if this is re-implemented to use the new UDF codegen approach then it would be gated on CometConf.COMET_SCALA_UDF_CODEGEN_ENABLED which is disabled by default.